home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-ietf-sip-bsd-api-00.txt < prev    next >
Encoding:
Text File  |  1993-04-06  |  22.7 KB  |  580 lines
  1.  
  2.  
  3. Internet Engineering Task Force                Robert E. Gilligan
  4. INTERNET-DRAFT                        Sun Microsystems, Inc.
  5.                             March 26, 1993
  6.  
  7.  
  8.  
  9.         SIP Program Interfaces for BSD Systems
  10.  
  11.  
  12. Abstract
  13.  
  14. In order to implement the Simple Internet Protocol (SIP) [1] in an
  15. operating system based on 4.x BSD, changes must be made to some of the
  16. application program interfaces (APIs).  TCP/IP applications written for
  17. BSD-based operating systems have in the past enjoyed a high degree of
  18. portability because most of the systems derived from BSD provide the
  19. same API, known informally as "the socket interface".  We would like the
  20. same portability to be possible with SIP applications.  This memo
  21. presents a set of changes to the BSD socket API to support SIP.  The
  22. changes include a new data structure to carry 64-bit SIP addresses, a
  23. new name to address translation library function, new address conversion
  24. functions, and some new setsockopt() options.  The changes are designed
  25. to be minimal and to provide source and binary compatibility for
  26. existing applications.
  27.  
  28.  
  29. Status of this Memo
  30.  
  31. Internet Drafts are working documents of the Internet Engineering Task
  32. Force (IETF), its Areas, and its Working Groups.  Note that other groups
  33. may also distribute working documents as Internet Drafts.
  34.  
  35. Internet Drafts are draft documents valid for a maximum of six months.
  36. This Internet Draft expires on September 26, 1993.  Internet Drafts may
  37. be updated, replaced, or obsoleted by other documents at any time. It is
  38. not appropriate to use Internet Drafts as reference material or to cite
  39. them other than as a "working draft" or "work in progress."
  40.  
  41. Please check the I-D abstract listing contained in each Internet Draft
  42. directory to learn the current status of this or any other Internet
  43. Draft.
  44.  
  45. Distribution of this memo is unlimited.
  46.  
  47.  
  48. 1. Introduction.
  49.  
  50. The most visible feature of SIP is its extension of the length of an IP
  51. address from 32 bits to 64 bits.  The APIs that the BSD system provides
  52. make the size of an IP address quite visible to an application.
  53. Virtually all TCP/IP applications for BSD-based systems have knowledge
  54. of the size of an IP address.  Generally speaking, those parts of the
  55. API that make addresses visible need to be changed.  This paper presents
  56. a first attempt to define the API changes needed to support SIP in BSD
  57.  
  58.  
  59.  
  60. systems. These APIs are expected to evolve as we gain more
  61. implementation experience.
  62.  
  63.  
  64. 2. Design considerations
  65.  
  66. There are two important considerations in designing changes to these
  67. well-worn APIs.  First, the modified API should provide both source and
  68. binary compatibility for programs written to the existing API.  That is,
  69. exiting program binaries should continue to operate when run on or
  70. re-compiled and run a system supporting the new APIs.  The API changes
  71. for SIP should not cause existing program binaries to break, nor should
  72. they cause programs written to the existing APIs to fail to compile or
  73. break when re-compiled.
  74.  
  75. Second, the changes should be as minimal as possible and should make it
  76. as easy as possible to change an existing application to be SIP
  77. knowledgeable.
  78.  
  79.  
  80. 2.1 What needs to be changed
  81.  
  82. Since their address arguments are all opaque pointers, none of the
  83. socket system calls need to changed directly.
  84.  
  85. The in_addr structure is 4-bytes long and can not be changed without
  86. breaking applications.  The sockaddr_in structure, which is passed into
  87. and returned by the socket functions, contains 8 bytes of unused space
  88. which can be used to hold a SIP address without incompatibility.
  89.  
  90. The gethostbyaddr() function includes an address type argument, so this
  91. function does not need to be changed.  However, the gethostbyname()
  92. function does not include a type argument, and most applications that
  93. use it assume that the address array that it returns consists of 4-byte
  94. IP addresses.  Thus a new function similar to gethostbyname(), but
  95. knowledgeable of SIP addresses, must be defined.
  96.  
  97. Finally, a new interface is needed in order to set the SIP flow ID.  The
  98. most straightforward way to do this is to define new setsockopt()
  99. options at the IPPROTO_IP level.
  100.  
  101.  
  102. 2.2 Implementation experience
  103.  
  104. The Sun IPAE/SIP prototype exposed some of the issues in designing a
  105. compatible interface.  The initial prototype passed SIP addresses
  106. between the kernel and applications using the sockaddr_in structure with
  107. the sin_family field set to AF_INET.  The 8-byte SIP address occupied
  108. the 4 bytes of the "sin_addr" field plus the first 4 bytes of the
  109. "sin_zero" field.  The kernel distinguished between 8-byte SIP addresses
  110. and 4-byte IPv4 addresses passed in by checking the sin_zero field.  If
  111. sin_zero was zero, the kernel would assume that the sin_addr field held
  112. a 4-byte IPv4 address.  If sin_zero was non-zero, it would assume that
  113. an 8-byte SIP address was being passed in.
  114.  
  115.  
  116.  
  117.  
  118. While this technique works for most existing applications, we discovered
  119. that some applications do not set the sin_zero field of the sockaddr_in
  120. structure to zero.  Thus we concluded that it would be unworkable in the
  121. general case and that some specific indication was needed to distinguish
  122. a 8-byte SIP address from a 4-byte IPv4 address in a sockaddr_in
  123. structure.
  124.  
  125. Another useful lesson learned from the initial Sun implementation was
  126. that the form of addresses (IPv4 or SIP) passed in and out of the socket
  127. functions did not always need to constrain the form of packets (IPv4,
  128. IPAE or SIP) transmitted or received.  For example, a pre-existing TCP
  129. server application that knows nothing of SIP could accept a connection
  130. that was transmitting and receiving TCP segments encapsulated within SIP
  131. packets.  Because SIP and IPv4 addresses are mappable, the accept()
  132. system call can return to the application the client's address as a
  133. 4-byte IPv4 address.
  134.  
  135. What does matter, however, is that pre-existing applications never be
  136. given address structures that they don't understand.  We found that the
  137. most convenient way for the kernel to decide what form of address to
  138. pass back to applications was to look at the form of addresses passed
  139. in.  That is, if an application passes in IPv4 form addresses, then it
  140. should always be given IPv4 form addresses.  If the application passes
  141. in SIP form addresses, the kernel can return SIP form addresses to the
  142. application.
  143.  
  144.  
  145. 3. Interface specification
  146.  
  147.  
  148. 3.1. New address family
  149.  
  150. We define a address family macro in <sys/socket.h>:
  151.  
  152.     #define AF_SIP        24    /* Simple Internet Protocol */
  153.  
  154. The AF_SIP definition is used only to distinguish between the original
  155. AF_INET form of the sockaddr_in structure, and a new form that we have
  156. defined.  Thus there is no corresponding PF_SIP definition.
  157.  
  158.  
  159. 3.2 Sockaddr_in structure
  160.  
  161. The sockaddr_in structure is used in the socket system calls to pass
  162. addresses between the application and the kernel.  Keeping the
  163. sockaddr_in structure the same size is necessary to provide binary
  164. compatibility for existing IPv4 applications.  We can avoid changing the
  165. size of the sockaddr_in structure by appropriating the currently unused
  166. sin_zero field to hold the 64 bit SIP address.
  167.  
  168. We can add a structure element for the SIP address without changing the
  169. original structure definition by just adding two new macros.  The
  170. resulting definition in the <netinet/in.h> header file is:
  171.  
  172.  
  173.  
  174.     struct sockaddr_in {
  175.         short sin_family;
  176.         u_short sin_port;
  177.         in_addr sin_addr;
  178.         char sin_zero[8];
  179.     }
  180. #define sip_addr sin_zero
  181. #define sip_zero sin_addr
  182.  
  183. The value of the sin_family field determines whether the sockaddr_in
  184. structure is holding a 32 bit IPv4 address or a 64 bit SIP address.  The
  185. sin_family field may have one of two values: AF_INET or AF_SIP.  If
  186. sin_family is AF_SIP, then the sip_addr field contains a 8-byte SIP
  187. address and the sip_zero field must be set to zero.  If the sin_family
  188. field is AF_INET, then the sockaddr_in keeps its original semantics: The
  189. sin_addr field contains a 4-byte IPv4 address and the sin_zero field
  190. must be set to zero.
  191.  
  192. We refer to the the two variants as the "AF_INET form" or the "AF_SIP
  193. form" of the sockaddr_in structure.
  194.  
  195. The two structure layouts can be understood better when viewed
  196. graphically.  This is the AF_INET form of the sockaddr_in structure:
  197.  
  198.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  199.     |           AF_INET             |       port number             |
  200.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  201.         |                         IPv4 address                          |
  202.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  203.         |                                                               |
  204.     +                        all zero bits                          +
  205.         |                                                               |
  206.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  207.  
  208. And this is the layout of the AF_SIP form of the sockaddr_in structure:
  209.  
  210.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  211.     |            AF_SIP             |        port number            |
  212.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  213.         |                         all zero bits                         |
  214.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  215.         |                                                               |
  216.     +                          SIP address                          +
  217.         |                                                               |
  218.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  219.  
  220. We considered an alternative form that overlays the high-order four
  221. bytes of the SIP address with sin_addr.  The form presented has a few
  222. advantages:
  223.  
  224.   -    The SIP address is aligned on a 64-bit boundary within the
  225.     structure.
  226.  
  227.   -    The kernel can do some consistency checking on AF_SIP addresses
  228.  
  229.  
  230.  
  231.     passed in. Because the sip_zero field, which overlays the
  232.     sin_addr field, must always zero, the kernel can detect cases
  233.     where the application incorrectly treats an AF_SIP form
  234.     sockaddr_in as an AF_INET form.
  235.  
  236.   -    The structure declaration is simpler than the alternative.
  237.  
  238. 3.3 The socket functions
  239.  
  240. Even though we define a new address family for SIP, there is no change
  241. to the way that applications get sockets.  There is not a new "type" of
  242. socket for SIP.  SIP applications continue use AF_INET in the "domain"
  243. argument (the first argument) of the socket() call.  For example, to get
  244. a TCP socket, a SIP application would call:
  245.  
  246.     s = socket (AF_INET, SOCK_STREAM, 0);
  247.  
  248. and to get a UDP socket, a SIP application would call:
  249.  
  250.     s = socket (AF_INET, SOCK_DGRAM, 0);
  251.  
  252. Once the application has a socket, it may use either the AF_SIP or the
  253. AF_INET form of the sockaddr_in structure in the system calls that pass
  254. addresses in to the kernel.
  255.  
  256. The form of sockaddr_in structure returned to the application by the
  257. socket functions is determined by the form of addresses passed in most
  258. recently.  For example, if an application uses an AF_SIP form address in
  259. its bind() call, then a subsequent accept() call would return a
  260. sockaddr_in structure in the AF_SIP form.  If the application calls no
  261. socket function that passes in an address before calling one that
  262. returns an address, then that function returns an AF_INET form address.
  263.  
  264. The socket functions to which an application passes in an address
  265. argument are:
  266.  
  267.     bind()
  268.     connect()
  269.     sendto()
  270.  
  271. The socket functions that return an address to the application are:
  272.  
  273.     accept()
  274.     recvfrom()
  275.     getpeername()
  276.     getsockname()
  277.  
  278.  
  279. 3.4 Sockets passed across exec()
  280.  
  281. Having two forms of sockaddr_in address that may be used interchageably
  282. with all AF_INET sockets means that existing applications are supported
  283. straightforwardly, and that new applications simply need to be written
  284. to use the AF_SIP form of sockaddr_in.  However, Unix allows open
  285.  
  286.  
  287.  
  288. sockets to be passed across an exec() call.  Thus a newly written
  289. application may find itself holding an open socket that was passed to it
  290. via exec(), but not knowing what form of addresses that will be
  291. returned.  Similarly, a newly written SIP knowledgeable application may
  292. wish to use AF_SIP form addresses in its bind() or connect() calls, and
  293. then pass the socket to a pre-existing application.  To remedy these
  294. problems, we defined a new setsockopt() option that allows an
  295. application to explicitly set the form of sockaddr_in addresses returned
  296. by the socket functions.  A SIP knowledgeable application that is passed
  297. an open socket from an unknown process may do use the SIP_ADDRFORM
  298. setsockopt() option to "convert" the socket to return AF_SIP form
  299. addresses.  Similarly, a SIP knowledgeable application that is about to
  300. pass an open socket to a program that may not be SIP knowledgeable may
  301. "downgrade" the socket to return AF_INET form addresses using the same
  302. setsockopt option.
  303.  
  304. The macro definition for this new option in <netinet/in.h> is:
  305.  
  306. #define SIP_ADDRFORM    0x16        /* get/set form of returned addrs */
  307.  
  308. The SIP_ADDRFORM option is at the IPPROTO_IP level.  The only valid
  309. option values are AF_SIP and AF_INET.  For example, to convert a socket
  310. to return AF_INET form addresses, a program would call:
  311.  
  312.     int addrform = AF_SIP;
  313.  
  314.         if (setsockopt(s, IPPROTO_IP, SIP_ADDRFORM, (char *) &addrform,
  315.                        sizeof(addrform)) == -1)
  316.         perror("setsockopt SIP_ADDRFORM");
  317.  
  318. An application may use SIP_ADDRFORM in the getsockopt() function to
  319. learn the form of addresses that will be returned by an open socket.
  320.  
  321.  
  322. 3.5 IPv4 addresses in AF_SIP form sockaddr_in structures
  323.  
  324. An application may need to pass 32 bit IPv4 address in a sockaddr_in
  325. structure, but want to set the sin_family field to AF_SIP in order to
  326. set the form of addresses to be returned.  To allow for this, we have
  327. defined a convention for storing 32 bit IPv4 addresses in 64 bit SIP
  328. addresses.  The 32-bit IPv4 address is stored in the low-order 32 bits
  329. of the SIP address and the high-order 32 bits (i.e. the prefix part) are
  330. set to zero.  For example, the following structure:
  331.  
  332.     struct sockaddr_in sin1;
  333.  
  334.     sin1.sin_family = AF_SIP;
  335.     sin1.sip_zero = 0;
  336.     *((long *) sin1.sip_addr) = 0;
  337.     *((long *) &sin1.sip_addr[4]) = inet_addr("192.9.9.1");
  338.  
  339. And this structure:
  340.  
  341.  
  342.  
  343.  
  344.     struct sockaddr_in sin2;
  345.  
  346.     sin2.sin_family = AF_INET;
  347.     sin2.sin_addr.s_addr = inet_addr("192.9.9.1");
  348.     bzero(sin2.sin_zero, sizeof(sin_zero);
  349.  
  350. are alternative ways to represent the same IPv4 address.
  351.  
  352. All of the socket functions that accept sockaddr_in addresses passed in
  353. as arguments accept IPv4 addresses in the AF_SIP form.
  354.  
  355.  
  356. 3.6 Flow IDs
  357.  
  358. The SIP header has a 28 bit field reserved to hold a "flow ID".  The
  359. usage of this field has not yet been specified.  But in order to allow
  360. application programmers to experiment with SIP flows, we have defined a
  361. setsockopt() option that can be used to set the value to be assigned to
  362. the flow ID field of transmitted SIP packets.  So far, we have not
  363. defined any interface for an application to learn the flow ID set in
  364. received SIP packets.
  365.  
  366. The macro definition for this new option in <netinet/in.h> is:
  367.  
  368. #define SIP_FLOWID              0x15    /* SIP flow identifier */
  369.  
  370. The SIP_FLOWID option is at the IPPROTO_IP level.  An example of how an
  371. application might use this option is:
  372.  
  373.     int flowid = 0x0f3c91ab; /* random value made up for this example */
  374.  
  375.         if (setsockopt(s, IPPROTO_IP, SIP_FLOWID, (char *) &flowid,
  376.                        sizeof(flowid)) == -1)
  377.         perror("setsockopt SIP_ADDRFORM");
  378.  
  379. The SIP_FLOWID option can also be used with the getsockopt() option to
  380. retrieve the flow ID value given in the last setsockopt() call.
  381.  
  382. Since the definition of SIP flows may change as the protocol develops,
  383. this option may also change in the future.  Thus application developers
  384. should consider this option "experimental."
  385.  
  386.  
  387. 3.7  Name-to-address translation functions
  388.  
  389. We have defined a new function call with the form:
  390.  
  391.      struct hostent *hostname2addr(const char *name, int af,
  392.                    char *buf, int buflen);
  393.  
  394. This interface looks the given host name up in the naming service and
  395. returns a list of addresses.  The name argument is the name of the host
  396. to look up.  The af argument specifies what form of address -- 4-byte
  397.  
  398.  
  399.  
  400. IPv4 or 8-byte SIP address -- to return to the caller in the h_addr_list
  401. field of the hostent structure.  The buf argument points to a buffer
  402. that the function can use to store the hostent structure that is
  403. returned.  The buflen argument is the size of the buffer.  If buf is a
  404. null pointer, the function uses its own static buffer.
  405.  
  406. If the af argument is AF_INET, hostname2addr() behaves like
  407. gethostbyname().  That is, it returns a hostent structure which includes
  408. an array of 4-byte IPv4 addresses.  If AA (SIP address) records are
  409. found, then the low-order 4 bytes of each SIP address are returned.  If
  410. only A records are found, then the associated 4-byte IP address is
  411. returned.
  412.  
  413. If the type argument is AF_SIP, then the h_addr_list field of the
  414. hostent structure contains an array of 8-byte SIP addresses.  If AA
  415. records are found, then the full SIP address of each record is returned.
  416. If only A records are found, then each 8-byte address returned holds the
  417. IPv4 address in the low-order 4 bytes and the high-order 4 bytes are set
  418. to zero.  (i.e. it uses the convention for storing IPv4 addresses in SIP
  419. addresses defined above).
  420.  
  421. There was some discussion on the SIP mailing list of some other ways to
  422. cast this function.  This proposal allows the application to be simple.
  423. Since it passes in the address family, the application knows the size of
  424. the returned addresses and can unconditionally bcopy() them into
  425. sockaddr_in structures.  Also, the semantics of the hostname2addr() when
  426. af is AF_INET lets us implement the existing gethostbyname() function in
  427. terms of the new function.
  428.  
  429. The gethostbyaddr() function remains unchanged:
  430.  
  431.      struct hostent *gethostbyaddr(const char *addr, int len, int af);
  432.  
  433. If the af argument is AF_INET, then len must be 4 and addr points to a
  434. 4-byte IPv4 address.  If af is AF_SIP, then len must be 8 and addr
  435. points to an 8-byte SIP address.
  436.  
  437.  
  438. 3.8 Address input/output functions
  439.  
  440. BSD Unix provides two functions -- inet_addr() and inet_ntoa() -- to
  441. convert IPv4 address between binary and printable form.  SIP
  442. applications need similar functions.  We have defined the following two
  443. functions to convert SIP and IPv4 addresses:
  444.  
  445.     int ascii2addr(long af, char *cp, char *ap);
  446.  
  447. and
  448.  
  449.     char *addr2ascii(long af, char *ap, char *buf, int buflen)
  450.  
  451.  
  452. The first function is used to transform an ascii string into an address
  453. data structure.  The af argument specifies that address family of the
  454.  
  455.  
  456.  
  457. address.  Currently AF_INET and AF_SIP are supported.  The cp argument
  458. points to the ascii string being passed in.  The ap argument points to
  459. the 4-byte or 8-byte buffer that the address will be converted into.
  460.  
  461. If the af argument is AF_INET, the function accepts a string in the
  462. standard IPv4 dotted decimal form:
  463.  
  464.     ddd.ddd.ddd.ddd
  465.  
  466. Where ddd is a one to three digit decimal number between 0 and 255.
  467.  
  468. If the af argument is AF_SIP, then the function accepts a string in the
  469. standard IPv4 dotted decimal form given above, or a string in one of the
  470. two standard SIP printing forms:
  471.  
  472.     xxxx:xxxx:ddd.ddd.ddd.ddd
  473. or
  474.     xxxx:xxxx:xxxx:xxxx
  475.  
  476. where xxxx is a 1 to 4 digit hex value and ddd is a 1 to 3 digit decimal
  477. number between 0 and 255.  If the string is in the IPv4 dotted decimal
  478. form, the high order 4 bytes of the address buffer pointed to by ap are
  479. set to zero and the low-order 4 bytes are set to the IPv4 address.
  480.  
  481. Having the AF_SIP variant of the ascii2addr() function accept either
  482. IPv4 addresses or SIP addresses allows an application to easily accept
  483. either form of address from the user.
  484.  
  485. The second function transforms an address buffer into a printable
  486. string.  The af argument specifies the form of the address.  This can be
  487. AF_INET or AF_SIP.  The ap argument points to a buffer holding a 4-byte
  488. IPv4 address or an 8-byte SIP address.  The buf argument points to a
  489. buffer that the function can convert into, and the buflen argument gives
  490. the size of this buffer.  If the buf argument is zero, then the function
  491. will convert the address unto a private static buffer of its own.  In
  492. either case, the function returns a pointer to the buffer that the
  493. address has been converted into.
  494.  
  495. The ascii2addr() function returns 0 if the conversion succeeded, and -1
  496. if it failed.  The function does not modify the storage pointed to by ap
  497. if the conversion fails.  The addr2ascii() function returns a pointer to
  498. the buffer if the conversion succeeded, and -1 if the conversion failed.
  499.  
  500. These two functions are derived from suggestions by Craig Partridge on
  501. the SIP mailing list.  There was some discussion about whether the
  502. buffer that addr2ascii() converts into should be static within the
  503. function() or passed in by the application.  In the interface presented
  504. here, we try to provide the best of both worlds.
  505.  
  506. 4. Open Issues
  507.  
  508. The API changes described here are likely to change as we get experience
  509. writing SIP applications.  There are also some issues left unresolved.
  510. Some of the things we need to think about are:
  511.  
  512.  
  513.  
  514.  
  515.   -    There is a type defined (in_addr) to represent a 32-bit IPv4
  516.     address.  Should we define a structure to hold the 64-bit SIP
  517.     address?  There was some discussion of this on the SIP mailing
  518.     list with opinions on both sides.
  519.  
  520.   -    The format of the "/etc/hosts" file currently supports only IPv4
  521.     addresses.  Should we extend the format of the existing file to
  522.     handle SIP addresses?  Or should we invent a file with a new
  523.     name for storing SIP host addresses?  Andrew Cherenson suggests
  524.     a clever, but ugly, hack to re-use the same file and allow old
  525.     and new versions of gethosb* to co-exist: precede SIP lines with
  526.     "#SIP", which acts as comment for old versions.
  527.  
  528.   -    How do datagram applications participate in path MTU discovery?
  529.  
  530.   -    What about the SIOC* ioctl() commands that get and set interface
  531.     parameters and manipulate the IP routing table?
  532.   
  533.   -    Posix is changing and standardizing the socket interface.
  534.     Should we track the posix changes?  In particular, 4.3-Reno has
  535.     split the 16-bit address family field of the sockaddr struct
  536.     into two 8-bit fields: a length field and an address family
  537.     field.  Should we adopt this here?
  538.  
  539.   -    This spec has concentrated on the BSD socket interface.  What
  540.     about the System V Transport Library Interface (TLI)?  Does
  541.     anyone really care about TLI?
  542.  
  543.   -    The BSD "net-2" release includes setsockopt options to set the
  544.     IP TTL.  Should we specify that this option sets the SIP hop
  545.     limit, or is this just obvious?
  546.  
  547.  
  548. 5. Security Considerations
  549.  
  550. Security issues are not discussed in this document.
  551.  
  552.  
  553. 6. Acknowledgements
  554.  
  555. Thanks to all who provided feedback to the first revision of this
  556. document, including Christian Huitema, Craig Partridge, Steve Deering,
  557. Andrew Cherenson, Charles Lynn, Ran Atkinson, Erik Nordmark, Glenn
  558. Trewitt, Fred Baker, Robert Elz, and Dean D. Throop.
  559.  
  560.  
  561. 7. References
  562.  
  563. [1]    Deering, S., "Simple Internet Protocol (SIP) Specification",
  564.     Internet Draft November 1992
  565.  
  566.  
  567.  
  568. 8. Authors' Address
  569.  
  570.     Robert E. Gilligan
  571.     Sun Microsystems, Inc.
  572.     2550 Garcia Avenue
  573.     Mailstop UMTV05-44
  574.     Mountain View, California 94043-1100
  575.  
  576.     415-336-1012
  577.  
  578.     bob.gilligan@eng.sun.com
  579.  
  580.